Sprint Demos
The sprint demo is an important part of Scrum that people tend to underestimate. Insist That All Sprints End With a Demo A well executed sprint demo, although it may seem undramatic, has a profound effect: * The team gets credit for their accomplishment. They //feel good//. * Other people learn what your team is doing. * The demo attracts vital feedback from stakeholders. * Demos are (or should be) a social event where different teams can interact with each other and discuss their work. This is valuable. * Doing a demo forces the team to actually finish stuff and release it (even if it is only to a test environment). Without demos, we kept getting huge piles of 99% finished stuff. With demos we may get fewer items done, but those items are really done, which is a lot better than having a whole pile of stuff that is just sort of done and will pollute the next sprint. If the team is more or less forced to do a sprint demo, even when they don't have much that really works, the demo will be embarrassing. The team will stutter and stuble while doing the demo and the applause afterwards will be half-hearted. People will feel a bit sorry for the team, some may be irritated that they wasted time going to a lousy demo. This hurts. But the effect is like a bitter-tasting medicine. Next sprint, the team will really try to get stuff done. They will feel that "well, maybe we can only demonstrate 2 things next sprint instead of 5, but dammit this time it's going to work!". The team knows that they will have to to a demo no matter what, which significantly increases the chence that there'll be something useful to demonstrate. Checklist for Sprint Demos * Make sure you clearly present the sprint goal. If there are people at the demo who don't know anything about your product, take a few minutes to describe the product. * Don't spend too much time preparing the demo, especially not on flashy presentations. Cut the crap out and just focus on demonstrating actual working code. * Keep a high pace, i.e. focus your preparations on making the demo fast-paced rather than beautiful. * Keep the demo on a business-oriented level, leave out that technical details. Focus on "what did we do" rather than "how did we do it". * If possible, let the audience try the product for themselves. * Don't demonstrate a bunch of minor bug fixes and trivial features. Mention them but don't demo them, since that generally takes too long and detracts focus from the more important stories. Dealing with "Undemonstratable" Stuff * **Team member:** "I’m not going to demonstrate this item, because it can’t be demonstrated. The story is ‘Improve scalability so system can handle 10,000 simultaneous users’ . I can’ t bloody well invite 10,000 simultaneous users to the demo can I?" * **Scrum master:** "Are you done with the item?" * **Team member:** "Yes, of course". * **Scrum master:** "How do you know?" * **Team member:** "I set the system up in a performance test environment, started 8 load servers and pestered the system with simultaneous requests". * **Scrum master:** "But do you have any indication that the system will handle 10,000 users". * **Team member:** "Yes. The test machines are crappy, yet they could handle 50,000 simultaneous requests during my test". * **Scrum master:** "How do you know?" * **Team member:** (frustrated) "Well I have this report! You can see for yourself, it shows how the test was set up and how many requests were sent!" * **Scrum master:** "Oh excellent! Then there’s your "demo". Just show the report and go through it with the audience. Better than nothing right?". * **Team member:** "Oh, is that enough? But its ugly, need to polish it up.". * **Scrum master:** "OK, but don’t spend too long. It doesn’t have to be pretty, just informative." Category:Scrum